
\chapter{Trabalhos Relacionados} 
\label{chapter:relatedWorks} 


Devido à grande atenção que o desenvolvimento de framewoks e modelos para
aplicações web tem recebido nos últimos anos, é que vários estudos têm sido
realizados, resultando em um grande número de plataformas que tentam facilitar o
desenvolvimento destas aplicações. Em geral, o foco destes trabalhos tem sido
resolver problemas específicos, como transações e qualidade de serviços
provendo segurança e confiabilidade. Algumas propostas,
muitas vezes tentam resolver problemas similares relacionados com composição
de serviços e equivalência semântica usando ontologias.

A finalidade da metodologia \textit{DM4PEWS} não é competir com
estas plataformas de aplicações web, mas sim trabalhar em cooperação com
algumas delas provendo um desenvolvimento organizado. A falta de uma
metodologia para este tipo de desenvolvimento motiva-nos a comparar a nossa proposta com algumas plataformas existentes para
desenvolvimento de aplicações web. Esta comparação pode ser justificada,
motivando assim o uso de \textit{DM4PEWS}, uma vez que nenhuma das plataformas
oferece uma metodologia de desenvolvimento que faça uso de
contratos e restrições de tempo. Assim, este capítulo apresenta algumas
plataformas, arquiteturas e modelos de aplicações web, comparando-os em
conformidade com as seguintes características: 

\begin{itemize}
  \item \textbf{Metodologia de desenvolvimento:} indica se há uma
  metodologia de desenvolvimento para aplicações web nos modelos propostos;
  \item \textbf{Modelo de qualidade:} indica se há um modelo para garantir a
  qualidade dos requisitos no desenvolvimento das aplicações;
  \item \textbf{Modelo de restrição temporal:} indica se há um modelo para
  restrições de tempo e se este é usado durante o projeto de desenvolvimento;
  \item \textbf{Avaliação semântica:} indica se há um avaliador semântico
   de serviços, de modo que se um serviço falhar, outro semanticamente
  equivalente possa ser invocado;
  \item \textbf{Validação de composição:} indica se a composição dos serviços
  é válida e se esta pode ser executada;
  \item \textbf{Avaliação de composição:} indica se há uma máquina para
  avaliação da composição de serviços;
  \item \textbf{Suporte a transação}: indica se existe suporte a transação para
  serviços web.
\end{itemize} 

\section{DbC para Serviços Web}

Heckel \textit{et al} \cite{HL05TACoS}, em seu trabalho, usa Design
by Contract (DbC) para serviços web e descreve diferentes níveis
de representação de contratos. O trabalho define 3 níveis para
especificação de contratos, sendo
eles: \textit{nível de implementação, nível de XML, nível de
modelo}.

\textbf{Nível de implementação:} Este nível de contrato é descrito na forma de
comentário em cada componente que representa o serviço web que será usado. Para
isso são usadas expressões booleanas sob forma de predicados. Como serviços são baseados em programação orientada a objetos,
várias linguagens de  especificação de contratos podem ser utilizadas, tais
como: \textit{Eiffel, JML, IContract} e \textit{JContract}.


\textbf{Nível de XML:} Este nível tem como foco a definição da interface WSDL.
O XML WSDL descreve a interface oferecida por um serviço como um conjunto de
operações e suas respectivas assinaturas. Este nível leva em consideração
apenas a descrição dos serviços através da especificação WSDL. No entanto, WSDL
não fornecer informações comportamentais sobre as operações. Para isso uma
extensão WSDL para operações com contratos resolveria este problema.

\textbf{Nível de modelo:} O autor argumenta que é melhor para o
especificação e execução de contrato trabalhar
em um nível modelo, ao invés que nos níveis de implementação e XML. O argumento
do autor para a aplicação de contratos em nível de modelos é: ``O 2 primeiros níveis
(implementação e XML) são difíceis de serem entendidos por pessoas e o tempo
gasto na sua implementação é alto. Deste modo, usando o modelo facilita tanto a
leitura, como o desenvolvimento e implementação das aplicações.'' Dessa forma os serviços web
baseados em contratos são de fácil aplicação, poupando tempo no entendimento
dos padrões de desenvolvimento WS-*.

O trabalho também apresenta conceitos que permitem verificação de serviços
web através do uso Design by Contract, adicionando informações
comportamentais às especificação dos serviços.  

\section{QoS para Serviços Web}


Este trabalho utiliza seleção e composição de serviços seb, não só
em conformidade com suas necessidades funcionais, mas também à suas propriedades de
transação e características de QoS usando um modelo de qualidade. Neste modelo
\cite{Haddad08}, os serviços web são selecionados de uma maneira que satisfaça preferências do
usuário. Preferências essas que são expressas como ``pesos'' sobre critério de QoS
e, como nível de risco, definindo semanticamente os requisitos transacionais.


A proposição principal deste modelo é fornecer um mecanismo que permita
selecionar um conjunto de serviços que satisfaçam não só os critérios de
qualidade definidos pelo usuário, mas também as propriedades transacionais
necessárias para garantir a execução fiável das aplicações. Workflows patterns são utilizados como
um meio para definir a estrutura de uma aplicação em termos de suas
funcionalidades e em termos da ordem de execução das atividades que o
compõem.


% \begin{figure}[ht]
% \centering 
% \fbox{
% \includegraphics[width=.5\textwidth]{figs/architecture.png}
% }
% \caption{Arquitetura Dirigida a QoS \cite{Haddad08}}
% \label{tab:exTable1}
% \end{figure}

\textbf{Arquitetura:} Este trabalho propoe uma arquitetura (figura
\ref{tab:exTable1}) para expressar propriedades comportamentais e
não-funcionais através de três componentes distintos: \textit{workflow, web
services registry} e \textit{composition manager}. Os (1) \textbf{\textit{workflows}} são regras
que representam o processo de negócio, e cada processo é composto de fragmentos
pequenos de workflow. O (2)
\textbf{\textit{Web Service Registry}} fornece os meios necessários para
registo e descoberta dos serviços. O componente (3)
\textbf{\textit{Composition Manager}} é composto por um motor que planeja o
mecanismo de execução dos serviços. Quando a composição dos serviços
(representada por um workflow) é iniciada, o mecanismo responsável pelo
planejamento dos contratos faz uma pesquisa por serviços para verificar os que
podem fazer parte da composição. Usando estes serviços, um plano de
execução é gerado para que, em seguida, o mecanismo de execução possa utilizar
e organizar os serviços que foram compostos para que a sua execução possa
ser iniciada.

\subsection{TCWS - \textit{Transactional Composite Web Service}}

Com base na definição das propriedades comportamentais, os autores
\cite{Haddad08} argumentam que a execução de serviços requerem propriedades transacionais. As propriedades
transacionais definidas são: \textit{pivot (p), compensatable (c)} e
\textit{retriable (r)}. Também são descrita novas propriedades a partir da
combinação das três primeiras. As propriedades são: \textit{pivot
retriable (pr)} e \textit{compensatable and retriable (cr)}.


São considerados ainda cinco critérios de qualidade para os serviços web, são
eles: \textit{preço de execução, duração, reputação, taxa de sucesso} e
\textit{disponibilidade}. Tais propriedades de QoS são
importantes para um processo de seleção e definição do modelo de QoS.

A partir das propriedades descritas, o trabalho apresenta um modelo de
composição baseado em transações chamado \textbf{TCWS} (\textit{Transactional
Composite Web Service}). TCWS é um
serviço composto que apresenta propriedades transacionais e comportamentais em
sua composição e sincronização. Um TCWS define
orquestração de serviços, especificando as dependências entre eles. As
propriedades comportamentais de um TCWS dependente de cada serviços
individualmente e do seu fluxo de execução. O modelo é centrado na descrição de
uma execução a partir do ponto inicial até o ponto final.


Para resumir, as propriedades comportamentais de um TCWS podem ser derivadas
dos serviços e de sua estrutura de execução. Os serviços são executados a
partir das propriedades transacionais de forma que a execução da composição 
ocorra obedecendo às propriedades definidas.


\section{WebTransact}

\textit{WebTransact} \cite{PiresBM02} é um framework que provê uma
infraestrutura necessária para a construção de serviços web compostos
confiáveis. O framework é composto de uma arquitetura multicamadas, de uma
liguagem baseada em XML chamada de \textit{WSTL (Web Services Transaction
Language)}, e é composto ainda de um modelo transacional.

% \begin{figure}[ht]  
% \centering
% \fbox{
% \includegraphics[width=0.8\textwidth]{figs/webTransact.png}
% }
% \caption{Arquitetura WebTransact \cite{PiresBM02}.}
% \label{fig:webtransact}
% \end{figure}
 
A arquitetura WebTransact encapsula o formato das mensagens, o conteúdo e
o suporte a transações dos serviços web. WebTransact integra serviços web
através de \textit{WSDL} e \textit{WSTL}: Web Service Description Language
(WSDL) descreve as interfaces dos serviços e, Web Service Transaction Language
(WSTL) é descrito sob uma extensão WSDL com funcionalidades para composição de
serviços

O framework define uma arquitetura de quatro níveis (figura
\ref{fig:webtransact}): \textit{Composition Layer, Mediator Service Layer,  Remote Service Layer} e
\textit{Web Service Provider Layer}. 

\textbf{Composition Layer:} Em WebTransact, uma composição é especificada usando
elementos WSTL. A composição é realizada a través de tarefas e é
representada por um grafo onde os nós representam os passos de
execução e as arestas representam o fluxo de controle e dados entre as
diferentes etapas. Uma tarefa de composição pode ser: (1) uma composição
atômica ou (2) outra tarefa de composição, sendo identificado  por um nome e uma
assinatura, (3) um conjunto de execuções, (4) um conjunto de dados, e
opcionalmente, (5) um conjunto de regras.

\textbf{Mediator Service Layer:} O mediador de serviço agrega equivalência
semântica aos serviços remotos. Serviços remotos semanticamente equivalentes
são serviços que integram serviços com diferentes interfaces WSDL propondo uma
visão homogeneizada de serviços heterogêneos.

\textbf{Remote Service Layer:} É a unidade lógica de trabalho que executa um
conjunto de operações remotas em um determinado site. Uma operação remota tem um
comportamento bem definido. Este comportamento define o nível de suporte a
transação de um dado serviço web.


\textbf{Web Service Provider Layer:} Nesta camada estão todas as descrições dos
serviços web utilizados. Da mesma forma a descrição transacional de
cada serviço (WSTL). A partir dos dados contidos nessa camada, os diferentes
serviços podem ser usados. As descrições são expressas em WSTL e diferentes
provedores de serviços são invocados quando necessário para usar cada serviço e
sua respectiva descrição transacional.
 
\section{WebFlowAH}

WebFlowAH \cite{MendesPDB09} é um ambiente para especificação e execução \textit{ad
hoc} de processos de negócio baseados em serviços web. Nesse caso, é
possível especificar os processos em termos dos requisitos dos usuários, que são
expressos com base em um domínio comum, e este domínio é baseado em ontologias. A semântica
dos processos de negócios e seus planos de execução são definidos usando
ontologias OWL-S.	

O analista de processo, para construir a sua especificação, não precisa saber
todos os detalhes necessários a execução do processo de negócio. WebFlowAH
compõe serviços através de um processo de síntese que permite a construção de
especificações completas dos processos de negócios, a partir de descrições de alto nível.


Alguns componentes que são definidos para este ambiente são: \textit{User
Interface, Workflow Manager, Service Manager, Semantic Composer,
Semantic Selector, Workflow Executer} e \textit{Semantic Repository}.

Cada componente é responsável por uma atividade específica no ambiente de
composição. A partir de uma definição abastrata do processo de negócio e sua
descrição semântica, a composição dos serviços presentes no repositório pode ser
realizada.
 
 
\section{ROSE}

Rose \cite{Hernandez-BaruchPZ07} é um software de coordenação de serviços
transacionais adaptáveis, sendo uma extensão de uma máquina de coordenação,
chamada Bonita \cite{bonita10}. Este trabalho é inspirado no conceito de
abordagens que usam separação de interesses (separation of concerns) e usa a
notação de contrato para expressar propriedades transacionais separada da
especificação de composição. A figura \ref{fig:rose} apresenta a estrutura da
abordagem Rose.	Para maiores detalhes deste framework, consultar
\cite{Hernandez-BaruchPZ07}.

% \begin{figure}[ht]  
% \centering
% \fbox{
% \includegraphics[width=.5\textwidth]{figs/rese.png}
% }
% \caption{Arquitetura Rose \cite{Hernandez-BaruchPZ07}.}
% \label{fig:rose}
% \end{figure} 
 
\section{Discurssão}

Comparar diferentes abordagens ajudará a identificar quais as necessidades
no desenvolvimento de aplicações web.
Diferentes trabalhos propõem modelos interessantes que resolvem problemas
específicos, tais como requisitos transacionais e equivalência semântica. No
entanto, quando estas abordagens decidem resolver em um problema
específico, acabam não tratando de outros problemas. Analisaremos estes
trabalhos levando em consideração as propriedades citadas no início deste
capítulo. 

As tabelas \ref{Tab:comparison} e \ref{Tab:comparison2} ilustram as
características analisadas. Apenas na proposta \textit{DM4PEWS} é definido um
desenvolvimento de aplicações web baseado em metodologia. As abordagens
\textit{WebTransact}, \textit{WebFlowAH} e \textit{Rose} não suportam modelos
de qualidade de requisitos. Estas abordagens visam o desenvolvimento de
aplicações baseado em arquiteturas pré-definidas a apenas a nossa proposta
propoe um modelo que tratar requisitos de restrição temporal para serviços web.
 
 
\begin{table}[!hbt]
\centering
\begin{tabular}{|c|c|c|c|c|}


 \hline {\bf } & Metodologia de & Modelo de & Modelo de   & Avaliação    
\\
  
  {\bf } & desenvolvimento  & qualidade &  restrição temporal  & semântica   
  \\

 \hline {\bf DM4PEWS} & \textbf{\textit{[sim]}} & \textbf{\textit{[sim]}} &
 \textbf{\textit{[sim]}}  & \textbf{\textit{[sim]}}   
 \\

 \hline {\bf WebTransact} & \textit{[não]}  &  \textit{[não]}  & \textit{[não]}  & 
\textit{[sim]}   \\

 \hline {\bf WebFlowAH} & \textit{[não]}  & \textit{[não]}  & \textit{[não]}  & 
 \textit{[sim]} 
 \\

 \hline {\bf ROSE} & \textit{[não]}   & \textit{[não]}   & \textit{[não]}    &
 \textit{[não]}  
  \\ 
  
   \hline {\bf DbC for} & \textit{[sim]}   & \textit{[sim]}  &  \textit{[não]} 
   &  \textit{[não]}
  \\
  {\bf Web Services} &  &  &   &   
  \\
  
   \hline {\bf TCWS} & \textit{[não]}  & \textit{[sim]}   & \textit{[não]}   &
   \textit{[não]}  
  \\
  

\hline

\end{tabular}
\caption{Comparação dos Trabalhos Relacionados.}
\label{Tab:comparison}
\end{table}

 
\begin{table}[!hbt]
\centering
\begin{tabular}{|c|c|c|c|}


 \hline {\bf } & Validação & Avaliação & Suporte a      \\
 
  {\bf } & de composição  & de composição &  transação  
  \\
 
 \hline {\bf DM4PEWS} & \textbf{\textit{[sim]}} & \textbf{\textit{[sim]}} &
 \textbf{\textit{[sim]}}  \\

 \hline {\bf WebTransact} & \textit{[não]}  &  \textit{[sim]}  & \textit{[sim]}  \\

 \hline {\bf WebFlowAH} & \textit{[não]}   & \textit{[sim]}  & \textit{[não]}   
 \\

 \hline {\bf ROSE} & \textit{[não]}   & \textit{[sim]}  &\textit{[sim]}    
  \\ 
  
   \hline {\bf DbC for} & \textit{[não]}   & \textit{[não]}   &   \textit{[sim]} 
  \\
  {\bf Web Services} &  &  &   
  \\
  
   \hline {\bf TCWS} & \textit{[não]}  & \textit{[sim]}   &  \textit{[sim]}  
  \\
  

\hline
 
\end{tabular}
\caption{Comparação dos Trabalhos Relacionados.} 
\label{Tab:comparison2}
\end{table}

Para as três propriedades apresentadas na Tabela \ref{Tab:comparison2},
apenas \textit{DM4PEWS} oferece validação de composição de serviços, todavia, só a abordagem
que faz uso de design por contrato, não define avaliação de serviços e o
ambiente \textit{WebFlowAH} não define suporte a transações.


Podemos ver que cada modelo citado apresenta características
positivas e outras apresentam algumas restrições, que normalmente são tratadas
por outras propostas. Nossa abordagem visa
superar o problema do desenvolvimento \textit{ad-hoc} para aplicações web,
fazendo uso de modelos de qualidade e execução temporal, além de um validador
de composição. Considerando esses
problemas, a metodologia \textit{DM4PEWS} apresenta uma proposta inovadora para
o desenvolvimento de aplicações web. A utilização da linguagem
PEWS, que é resultado de projetos de pesquisa, ajudará na implementação das
atividades da metodologia. Assim, \textit{DM4PEWS} visa assegurar
um desenvolvimento ordenado, gerando aplicações web confiáveis e de qualidade.
